Stop MCP authorization recovery from looping reconnects - #857
Conversation
TheGreatAxios
left a comment
TheGreatAxios
left a comment
There was a problem hiding this comment.
Verdict: approve (GitHub cannot approve own PR).
CL-7528 holds at 315f2c0. Recovery is coordinated per connection: refresh before browser, 3-prompt cap with cooldown, first PKCE verifier wins, onAuthorized and cap-clear only after verified recovery, close() aborts OAuth via lifecycle, abort during refresh does not emit a browser prompt, and a later recovery generation cannot steal a prior episode notify.
Focused MCP auth tests: 43 pass, 0 fail. bun run typecheck exit 0. ESLint on touched files: 0 errors.
No blocking findings remaining from the in-session review loop.
Linear MCP servers periodically disconnect and every auth failure fell through to a browser re-auth prompt. The provider now performs a refresh_token grant against discovered authorization server metadata before any browser flow, and browser prompts are capped at three per server with a five minute cooldown, surfacing a clear error through the connect failure path instead of looping forever.
28de297 to
ff2bea7
Compare
|
Follow-up: HEAD |
Reconnect during an in-flight browser wait was starting a new coordinator and prompting again. An ignored tab left connect pending until abort.
1 participant
Summary
onAuthorizedfire only after the retried call succeeds, andclose()aborts in-flight OAuth even when connect supplied an external signalVerification
bun teston the four MCP auth files: 39 pass, 0 failbun run typecheckexits 0bun run buildexits 0bun run check:projects-dir-guardexits 0Promise.withResolvers<void>()insrc/mcp/client.tsis fixedFixes CL-7528